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Introduction 

Many problems in transportation can be represented 
as flow problems, and can be optimally solved us- 
ing efficient linear programming techniques [BHM77] 
[BGAB83]. But in some cases this approach is seri- 
ously oversimplified. If the problem includes depen- 
dencies between different operations, planning is nec- 
essary. If the system parameters change dynamically, 
the a ssum ptions on which flow models are based be- 
come false, as in the case when the capacity of trans- 
portation facilities can change during the interval be- 
ing analyzed. Finally, if detailed schedules are to be 
produced, answers in terms of bulk quantities do not 
suffice. 

These problems require approaches that combine ca- 
pabilities traditionally associated with planning and 
with scheduling, and that do not require their param- 
eters to remain constant. Historically, temporal plan- 
ners [DFM88] [AK83] have dealt with combining gen- 
eral" operators to achieve a set of goals over time but 
have poorly attended to issues related to the optimiza- 
tion of resource usage. On the other hand, schedulers 
[SOP+90] [Sad9l] have been concerned with allocat- 
ing times and resources to operations in fixed pro- 
cess plans, ignoring questions of goal-oriented prob- 
lem solving. The HSTS temporal planning framework 
[MSCD91] is an attempt to combine the capabilities of 
the two approaches. HSTS has been previously used 
for planning and scheduling the observations for the 
Hubble Space Telescope. HSTS emphasizes the de- 
scription of the problem domain as a dynamical system 
organized through the use of state variables, i.e. per- 
sistent properties of objects in the domain. It also al- 
lows the development of opportunistic planners, where 
constraint posting and temporal inferences are not re- 
stricted to predefined directions on the time horizon 
(as in simulation and temporal projection) but the fo- 
cus of problem solving can concentrate on the most 
congested areas of the time line. 

In this paper we describe preliminary work done in 
the CORTES project [FS90], applying HSTS to a trans- 
portation planning and scheduling domain. First, we 
describe in more detail the transportation problems 
that we are addressing. We then describe the funda- 
mental characteristics of HSTS and we concentrate on 
the representation of multiple capacity resources. We 
continue with a more detailed description of the trans- 


portation planning problem that we have initially ad- 
dressed in HSTS and of its solution. Finally we de- 
scribe future directions for our research. 

The transportation problem 

We are interested in addressing large-scale, complex 
transportation planning and scheduling problems, such 
as are found in disaster relief operations or other large- 
scale, international responses to emergency situations. 
For example, the transportation aspects of military op- 
erational plans (or OPLANs) must be feasible, given 
the allocated transportation resources [Han88]. If not, 
they must be reworked, or have more resources al- 
located to them. OPLANs are very large, involving 
the movement of tens of thousands of individual units, 
which vary immensely in size and composition, from 
a single person or piece of cargo to an entire division. 
However, OPLANs do not explicitly represent justi- 
fications for precedence constraints due to the struc- 
ture of the domain and are therefore difficult to mod- 
ify or adapt to other situations. To concentrate on the 
representation of domain structure in a transportation 
schedule, we addressed the ‘bare base’ deployment sce- 
nario used at the Armed Forces Staff College (AFSC) 
to train joint planning officers. The goal is to turn a 
bare runway into a fully functioning air base. Doc- 
uments are available from AFSC describing scenario 
assumptions and types of available units, including rec- 
ommended sequencing, and some hints at the depen- 
dencies between units. This domain includes only 92 
unit types, in 40 general categories. It is also simpli- 
fied in that OPLANs generally involve much more than 
deploying a single air base, and more than one armed 
service. 

Our analysis of the bare base domain revealed two 
facts: 

• The domain requires the ability to represent and rea- 
son about aggregate capacity resources. 

♦ This domain consists primarily of a moderate num- 
ber (order of 10) dependency cycles, each centered 
around a different support function, such as air traf- 
fic control, aircraft refueling, personnel or cargo un- 
loading, etc. The arrival of support units increases 
the possible arrival rate of additional support units. 

We isolated one of the dependency cycles, the refu- 
eling capacity /throughput loop, as an initial ‘atomic’ 
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domain. A demand on the base refueling capac- 
ity, an aggregate resource, can be satisfied by bring- 
ing more refueling units to the base. The arrival of 
a unit permanently increases refueling capacity, which 
in turn affects the rate at which planes can arrive, 
since they use some amount of refueling capacity im- 
mediately after moving. This increases also the rate at 
which additional units can be brought in. These sim- 
plified refueling units have no support requirements, 
so when they are operational at the base they increase 
its capacity, without requiring any other units to be 
brought in. 

The representation and solution of this problem is 
an important step toward a solution of the bare base 
scenario. 

Representing plans in HSTS 

Transportation problems require to be able to deal 
with dependencies involving state and resource capac- 
ity (e g., a unit that requires a plane to move from A 
to B can be allocated space only on a plane that is also 
moving from A to B). This can be done by using the 
HSTS planning and scheduling framework [MSCD91], 
The two main components of the framework are a do- 
main description language, for modeling the struc- 
ture and dynamics of the physical system at multiple 
levels of abstraction, and a temporal data base, for 
representing possible evolutions of the state of the sys- 
tem over time. 

_ In this section we describe the basic primitives pro- 
vided by HSTS and the extensions needed to represent 
a gg re g a te resource capacity. 

Representing state 

An HSTS model is subdivided into state variables, 
each of which can assume one and only one value in any 
instant of time. A value has the form R(x i , r 2 , • . • , x n ). 
For example,, a plane ?p has a location, represented 
by state variable Loc(?p), that can assume value 
MOVE(?p,?u,?src,?dst) representing the fact that ?p 
is in transporting unit ?u from location ?src to location 
?dst. HSTS is interval based, i.e., if a value occurs on a 
state variable, it persists for a continuous non-zero time 
interval. A value can occur under conditions specified 
through a duration specification and a compati- 
bility specification. 

Figure 1 shows a hypothetical value descriptor. The 
duration is expressed as a range constraint, [d,Z>], 
with d and D representing respectively a lower bound 
and an upper bound function. The rest of the descrip- 
tor specifies the compatibilities that have to be sat- 
isfied. A compatibility specification is an AND/OR 
graph connecting several elementary compatibilities. 
Each compatibility is composed of a temporal rela- 
tion and the specification of a segment of behav- 
ior on a state variable. For example the compat- 
ibility [met.by (v, Loc(?p), AT^src))] associated to 
( Loc(?p),MOVE(?p,?u,?src,?dst )) in Figure 1 sped- 
fies that in every legal behavior, the value MOKE must 
occur immediately after the value AT on Loc(?p). The 
symbol v is one of two different kind of segments of 
evolution of a state variable: v , constraining a single 


< Loc(?p ), MOVE(?p,?v,?src, ?dst)) 


duration 
compatibi 
AND ( 


dvr(?sTC, ?dsi), Dur(?src,?dst)] 
lities: 

mei-by (u, Loc(?p), AT(?src))] 

[meets (./, Loc(?p), REFUEL^ dst))] 

eql (i/, Loc(?u), MOVE(?p, ?u, ?src, ?ds<))]) 


Figure 1: HSTS value descriptor 


value, as in the example above, and a, for sequence 
compatibilities. A sequence that can be substituted by 
an unspecified number of values occurring on the same 
state variable, all of which must satisfy a constraint 
associated with the sequence. We will see examples 
of sequences when we will discuss aggregate capacity 
state variables. 

Behaviors can be constructed within the HSTS Tem- 
poral Behavior Data Base. The unit of descrip- 
tion of temporal behavior is the token, a quadruple 
{sv, type, st, ei), where sv is one of the state variables 
in the system model, type is a subset of the state vari- 
able’s possible values, and st and et are the token’s 
start and end times respectively. Tokens represent an 
uninterrupted segment of evolution of a state variable. 
During the planning process a token can be refined 
by being split into any number of component tokens; 
however, a token that has been designated to repre- 
sent the occurrence of a value cannot be further split. 
A token that can be split is referred to as a plan con- 
straint; one that cannot be split is referred to as a 
plan value. The TDB also allows the representa- 
tion of token sequences which implement the occur- 
rence of a sequence specification. Tokens and token 
sequences are connected by a network of constraints: 
temporal constraints, relating the start and end 
times of each token, and type constraints, referring 
to the type of each token. Temporal and type con- 
straints derive either from the expansion of compatibil- 
ities and durations extracted from the model of the sys- 
tem, from requirements directly imposed by the user 
and therefore constituting the problem to be solved, 
or from refinement decisions taken during the prob- 
lem solving process where one of multiple alternatives 
needs to be explored. 

Representing Aggregate Resource 
Capacity 

At the base of the HSTS representation philosophy is 
the assumption that it is possible to identify each state 
variable into which a system model is decomposed and 
that each state variable can assume one of a handful 
of symbolic values. However, this basic mechanism of 
representation can become very cumbersome. For ex- 
ample, to reason on the allocation of available space 
on a plane to materials, we would have to subdivide 
space on the plane into “unit of space” state variables, 
with values ‘free’ or ‘used’, subdivide also the materials 
into units of space, and allocate capacity each unit of 
material space to a unit of plane space. Although this 
might be necessary for a detailed map of the allocation 
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of plane space, it is overly detailed for cases when we 
need only an aggregated characterization of the use of 
space. 

HSTS can represent aggregated capacity as an ag- 
gregate state variable. The value of an aggregate 
state variable at a given time is a summary of the value 
of a corresponding set of atomic state variables at the 
same instant of time. In the transportation planning 
domain, the use of cargo or parking space or the gen- 
eration or use of refueling capacity by a unit or plane 
at a base falls into this category. 

A set of atomic state variables constitutes the con- 
ceptual base on which the aggregation is built. In our 
discussion, they are atomic resources that can be 
used by one and only one operation at a time. An 
operation OPi is the value assumed by the state state 
variable of a job ?j, St(?j), while ?j is undergoing the 
specified operation. If ?j is not undergoing any opera- 
tion, the value of St(?j) is IDLE . An atomic resource ?r 
has a single atomic state variable, St(?r), with possible 
values OPER (processing some operation) and IDLE . 

The occurrence of OPi and of OPER is regulated by 
the following bidirectional compatibility: 

W> St(?j), OP i)[eql (i/, $<(?r), OPER)] 

If the atomic resources in a pool ?r_p are perfectly 
substitutable, they can be aggregated into a single ag- 
gregate state variable, the aggregate processing ca- 
pacity of the pool, Cap(?r-p). At any instant of time, 
the aggregate state variable will assume a single value 
that will summarize the distribution of values over its 
component state variables at that time. Cap(?r.p) 
gives the number of resources in the pool that hold 
each of the values OPER and IDLE ; its values are rep- 
resented as follows: 

{(OPER,n x ),(IDLE,n 2 )} 

indicating that n\ atomic resources in ?rjp are in an 
OPER state and n 2 are in an IDLE state. The number 
of resources in ?r~p at that instant of time is n x + n 2 . 
In general, a value for an aggregate state variable is a 
list of such entries (value, counter). 

Compatibility constraints on values of aggregate 
state variables specify one or more atomic values and, 
for each value, the number of atomic resources affected. 
For example, assuming that OP, requires c, atomic re- 
sources, we will have: 

(St(?j), OPi) -> [eql (a, Cap(?r.p), (OPER, INC(+«)), 

(IDLE,INC(-«))}] 

This means that whenever OP,- occurs, a sequence of 
values must be found on Cap(?r_p), and the start and 
end times of the sequence must coincide with the start 
and end of OP,*, as indicated by the temporal relation 
eql The type specification describes the local effect of 
the compatibility on each of the values in the sequence, 
i.e, the number of atomic resources that are OPER is 
incremented by -he*, while the number of those that 
are IDLE is decremented by c,-. 

At time r, the actual value of an aggregate state 
variable can be computed once the set of constraints 
that contain r is known. In the case of <7ap(?r_p), if we 
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Figure 2: Posting a sequence constraint on an aggre- 
gate capacity state variable 

suppose we have entries of type (OPER, INCfe)) 
and n idU entries of type (IDLE, INC (cj)), the value 
{(OPER, r»i), (IDLE, n 2 )} at time r satisfies the rela- 
tions: 

«i£U 

"1 = ^2 * ”2 = 2 C > 

«=1 3=1 

where c,* and Cj can be both positive (creation) or 
negative (consumption). 

During the planning process, the evolution of an ag- 
gregate state variable is represented in the temporal 
data base by a sequence of plan constraints determined 
by the imposition of a set of sequence constraints (Fig- 
ure 2). Note that the temporal extension of each ag- 
gregate state variable’s value is not fixed. This is an 
important difference from other scheduling systems, 
where the times must be fixed if the values of aggregate 
capacities are to be fixed [SOP + 90] [Sad9l]. 

Consistency of the state of a temporal data base can 
be checked by temporarily assuming that no more se- 
quence constraints will be posted and, therefore, the 
plan constraints can be safely substituted with plan 
values that can be computed by applying constraints 
like those for ni and n 2 , above. The data base will 
be inconsistent when an aggregate value contains a 
counter whose value is negative. Notice however that, 
in the case where the physical system allows the gen- 
eration of capacity (as for aggregate processing ca- 
pacity), pwtial inconsistency can be resolved without 
backtracking by posting additional compatibilities pro- 
viding the missing capacity. 

Planning within HSTS 

The atomic domain was intended to demonstrate that 
the new extensions to HSTS for this type of do- 
main (principally those for handling aggregate capac- 
ity) function correctly, and provide the necessary prim- 
itives to solve the fundamental problems that such a 
domain presents. 

The atomic domain representation 

The state variables in this domain are the refueling and 
throughput properties of three types of objects: units, 
planes, and bases. 
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Each unit has two associated state variables, its lo- 
cation Loc and its state St A unit’s Loc can have the 
values AT and MOVE. These correspond to the unit 
being stationed at some base (e.g., home or destinar 
tion) or being in transit. A unit’s St can have the val- 
ues NOT-OPER or OPER. These indicate whether it is 
capable of providing refueling capacity. When OPER, 
it adds enough capacity to refuel one additional plane. 
Each plane has one state variable, Loc y which can have 
the values IDLE, MOVE , and REFUEL. 1 . A base 
has one aggregate state variable, its refueling capac- 
ity R-C, containing distributions of two values, AVAIL 
and USED, indicating the total amount of available 
and used refueling capacity at any time. The principal 
compatibilities describing this problem are: 

• The MOVE of a unit is followed by it being OPER 
some non-zero amount of time later 2 : 

{Loc(?u) ) MOVE(?p,?u i ?src,?b)} 

[bf([St } 6t]) (^St(?u), OPER(?u } ?b))] 

• The MOVE of a unit is concurrent with the MOVE 
of a plane: 

[tql {u, Loc(?p ), MOVE(?p , ?*, ?srr, ?6))] 

• The MOVE of a plane is immediately followed by 
REFUEL : 

(Loc(?p) 1 MOVE(?p 1 ?u,?src } ?b)) 

[meets {u, Loc(?p ), REFUEL(?p, ?&))] 

• The unit increases R-C(?b) while it is OPER : 

(St(?u), OPER(?u,?b)) 

[eql (a, R-C(?b), {(A VAIL , INC(+l)}}] 

• The REFUEL of the plane creates a demand on 
/LC(?5): 

{ Loc(?p ), REFUEL(?p,?b)) -► [tql (cr, R.C(?b), 

{ ( USED , INC(+ 1)) , (A VAIL , INC{- 1)> })] 

The atomic domain planner 

The HSTS model of a domain describes domain con- 
straints in terms of durations of and compatibilities 
between values of state variable tokens, as described 
previously. This creates an implicit space of legal sets 
of state variable value sequences, within which any par- 
tial (or complete) solutions to problems in this domain 
must lie. 

However, in order to describe any specific partial 
solution, a particular set of legal choices must be made. 
Many such sets of choices will result in inconsistent sets 
of compatibilities, not corresponding to any possible 
system behaviors. Finding a consistent set of choices 
(i.e., planning) can still be very difficult. Within the 
HSTS least-commitment framework, the final solution 

1 For this abstract model, representing refueling state 
and location separately would have introduced irrelevant 
complications. 

2 This is necessary to prevent a degenerate problem, 
where each unit brought in adds enough capacity to han- 
dle its own plane, thus immediately allowing an arbitrary 
number of units to be brought in. 


is a representation of a range of behaviors that can be 
directly simulated, all guaranteed legal. 

In the case of transportation planning and schedul- 
ing, one must select actual units to supply required 
support, and select actual ranges of arrival times for 
these units. This selection is ultimately based on the 
needs of some set of units whose operation at the desti- 
nation directly fulfills external (top-level) goals. These 
top-level units require support of various kinds, and 
their support units in turn require support. Any of 
these units not already at the destination need to be 
transported there. 

Thus, any unit that needs to be transported ulti- 
mately serves a top-level goal through some chain of 
dependencies. This means that the planner can work 
by finding ‘operators’ that satisfy goals, and then other 
‘operators’ that provide these operators’ preconditions 
and fix problems from their postconditions; except 
that, in HSTS, the planner is assigning values to cer- 
tain time intervals of state variables, and using the 
compatibilities between these values and other values 
as ‘preconditions’ and ‘postconditions’. 

The planning goal is represented as a request for a 
large amount of USED refueling capacity during some 
future interval. The posting of the request creates an 
interval of time in which the AVAIL capacity is nega- 
tive. 

The planning process begins with an HSTS fetch 
for intervals where the base refueling capacity is below 
zero, locating the top-level problem. The planner then 
finds which types of values provide the type of capac- 
ity needed, and which state variables can have these 
values. It selects enough instances of these variables 
to satisfy the demand, creates the appropriate value 
tokens for them, and constrains these tokens to occur 
over the required interval. This solves the top-level 
problem. 

Then, for each of these state variables, its token’s 
compatibilities are implemented, that is, constraints 
between the token and other values are enforced, to 
guarantee that this is a legal behavior. Single-unit 
compatibilities are done first, followed by those that 
affect other units. This ordering is important in gen- 
eral, since local constraints may limit the choices avail- 
able to more global ones. This corresponds to classical 
systems having process plans for individual jobs be- 
fore scheduling their operations. Since dependencies 
between different units of the same type are expressed 
through aggregate variables, this ordering is equivalent 
to saying that compatibilities that do not affect aggre- 
gate variables are done first. The set of local compat- 
ibilities in this domain are simply the first three listed 
in the previous subsection. 

Next, the compatibility for the effect of plane refuel- 
ing on the aggregate capacity is implemented. This 
requires the choice of a particular time interval for 
plane refueling, relative to the intervals of different lev- 
els of aggregate capacity. This is done in one of three 
modes: planes are allocated times as late as possible, 
as early as possible, or at user-selected times. This 
variability demonstrates the complete flexibility of the 
order of decisions in ‘simulated time’ (time in the mod- 
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eled domain). This flexibility allows for opportunis- 
tic decision-making, where decisions are made in the 
most efficient order, not in any pre-determined tempo- 
ral order. Other temporal planners generally cannot 
make decisions this flexibly when working at the most 
detailed level. 

Finally, the effect of the unit becoming operational 
on the aggregate capacity is implemented. In both of 
these last two steps, some search may be needed. The 
interval initially chosen may not produce a legal con- 
figuration, due to the simple mechanism for picking 
an interval and a limitation of the current aggregate 
variable mechanism. Currently, once the contribution 
from a state variable to an aggregate variable is calcu- 
lated, its relative position in the aggregate cannot be 
changed without backtracking. This violates the least- 
commitment principle, and leads to problems: some 
intervals on the aggregate variable have zero length. If 
our simple interval selection rule selects a zero-length 
interval for a non-zero length event, an inconsistency 
results. Currently the easiest way to handle this is 
to implement, detect the inconsistency, and backtrack. 
Very limited search is needed, since non-zero intervals 
are much more frequent. Fixing this failure of least- 
commitment is high on our research agenda. 

When these steps have been carried out for the nec- 
essary number of variables, a complete and consistent 
behavior has been described that fulfills the top-level 
goals. 

Conclusion 

Temporal planning methodologies can be applied to 
solve transportation planning problems that are be- 
yond the scope of traditional linear programming tech- 
niques. In our work we have addressed one such 
problem and identified a fundamental type of depen- 
dency among its entities. We have then demonstrated 
that problems involving this kind of dependency can 
be solved within the HSTS temporal planning and 
scheduling framework. To solve the full bare base de- 
ployment scenario, we need to extend our current prob- 
lem solver to incorporate heuristic knowledge in order 
to select the most appropriate units and time intervals 
for values, and carry out local search if necessary. 

In order to deal with real-world scale problems, 
it will be necessary to develop further problem ag- 
gregation and abstraction techniques. One promis- 
ing direction concentrates on taking advantage of the 
temporal flexibility of the HSTS framework by com- 
bining least-commitment constraint posting method- 
ologies with probabilistic estimates of resource usage 
[MS87]: the goal is to avoid spelling out unnecessary 
details whenever possible while insuring high quality 
possible executions of the temporal plan. 
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